-
Notifications
You must be signed in to change notification settings - Fork 13.5k
hir_analysis: add missing sizedness bounds #142712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
hir_analysis: add missing sizedness bounds #142712
Conversation
rustbot has assigned @petrochenkov. Use |
HIR ty lowering was modified cc @fmease |
This comment has been minimized.
This comment has been minimized.
Wasn't expecting that failure, looking into it. |
A smaller example of one of the failing crates (which happens with a stage two build): #![crate_type = "lib"]
use std::marker::PhantomData;
pub trait ZeroMapKV<'a> {
type Container;
}
pub trait ZeroFrom<'zf, C: ?Sized> {}
pub struct ZeroMap<'a, K: ZeroMapKV<'a>>(PhantomData<&'a K>);
impl<'zf, 's, K> ZeroFrom<'zf, ZeroMap<'s, K>> for ZeroMap<'zf, K>
where
K: for<'b> ZeroMapKV<'b>,
<K as ZeroMapKV<'zf>>::Container: ZeroFrom<'zf, <K as ZeroMapKV<'s>>::Container>,
{
}
|
r? types |
I'd like to think about this... Can you remind me, is |
Yes, it is |
Default sizedness bounds were not being added to `explicit_super_predicates_of` and `explicit_implied_predicates_of` which meant that a trait bound added to a associated type projection would be missing the implied predicate of the default sizedness supertrait of that trait. An unexpected consequence of this change was that the check for multiple principals was now finding an additional `MetaSized` principal when eagerly expanding trait aliases. Instead of special-casing trait aliases as different from traits and not adding a `MetaSized` supertrait to trait aliases, filter out `MetaSized` when lowering `dyn Trait`.
I think this highlights a problematic interaction with trait aliases, and I'm tempted to say that trait aliases should have their behavior reworked to stop expanding into their bounds in FOr now, I think it's inconsistent to not add |
60d5044
to
7684842
Compare
Changed to this, thanks. Still hitting the stage two failure, though I've added a UI test with my reproduction so that will fail first, not had much progress on working out what's going wrong with it. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Default sizedness bounds were not being added to
explicit_super_predicates_of
andexplicit_implied_predicates_of
which meant that a trait bound added to a associated type projection would be missing the implied predicate of the default sizedness supertrait of that trait.An unexpected consequence of this change was that the check for multiple principals was now finding an additional
MetaSized
principal when eagerly expanding trait aliases - this required modifying lowering to no longer add default bounds to trait aliases.